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In Claim 27, line 7, delete "into", and substitute therefor 
--with-- . 



Claims 1-27 are pending in this application, and stand 
rejected pursuant to the Examiner's Office Action dated 
4/10/91. Applicants have amended the specification and claims 
in response thereto, and request the Examiner reconsider the 
rejection of these Claims 1-27. The following comments follow 
the order of the Examiner's comments, to facilitate issue 
resolution. 

The Examiner has required correction of the Abstract, 
based on Applicants' use of the term "means". Applicants have 
amended the Abstract to eliminate such usage. 

The Examiner next rejected Claims 1-27 under 35 U.S.C. 
112, second paragraph, as being indefinite. As to Claim 1, 
the Examiner points out improper antecedent basis for "the 
selected items" and "the data". Applicants have amended Claim 
1 in response thereto. The Examiner further states that "... 
associating ... into ..." is vague in Claim 1. Applicants 
have further amended Claim 1, in changing the word "into" to 
"with" to clarify the dynamic association. Specification 
support for this change is found at Specification page 12, 
lines 20-35. The association description in the Specification 
is further discussed at Page 27, lines 7-13. 

Next, the Examiner rejected Claim 4 for improper antece- 
dent basis for "said hierarchical relationship" and "said at 
least two interface objects". Applicants have amended Claim 4 
to be dependent on Claim 3, and not Claim 2, where such 
elements have been previously defined. 

AT9-89-039 4 



In Claim 27, lim 




delete "the 



it 



Remarks 



PATENT 
07/352,530 



The Examiner rejected Claim 5 for improper antecedent 
basis for "the objects'*, "said objects", and "the data". 
Applicants have amended Claim 5 to clarify that "the objects" 
and "said objects" are "interface objects", which have been 
previously used. 

The Examiner rejected Claim 11 for improper antecedent 
basis for "said constructed command". Applicants have amended 
Claim 11 to eliminate the term "constructed" . 

The Examiner rejected Claim 12 for improper antecedent 
basis for "said executed command". Applicants have amended 
Claim 11 to eliminate the term "executed". 

The Examiner rejected Claim 13 for improper antecedent 
basis for "the data". Applicants have corrected this problem 
by eliminating "the" . 

The Examiner rejected Claim 14 for improper antecedent 
basis for "said objects". Applicants have amended Claim 14 to 
clarify that these are "interface objects". 

Next, the Examiner rejected Claim 15 in stating "said 
data" lacks proper antecedent basis. Applicants have elimi- 
nated "said" from this element. 

Claim 18 was rejected by the Examiner stating "the 
interface data database", "said altered interface", and "said 
same session" lacked proper antecedent basis. Applicants have 
amended Claim 18 to correct these deficiencies. Applicants 
aire claiming means for altering "the "object database", and 
have corrected the first usage of "altered interface" and 
"same session". 

The Examiner rejected Claim 19 as having improper antece- 
dent basis for "said interface object database". Applicants 
have deleted' the term "interface" from this element to clarify 
that the object database is being altered. 
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Claim 20 was rejected by the Examiner for having improper 
antecedent basis for "said hierarchy of interface objects" and 
"said hierarchy". Applicants have amended Claim 20 to correct 
these antecedent basis problems. 

The Examiner rejected Claims 22 and 23 in stating that 
"said interface data objects" lacks antecedent basis. Appli- 
cants have amended Claims 22 and 23 to delete the term "data", 
and thus clarify that "interface objects" are being claimed. 

Next, Claim 24 was amended by Applicants in response to 
the Examiners suggestion to correct a typing error. 

Claims 26 and 27 were rejected by the Examiner for 
reasons similar to Claim 1, and Applicants have corrected 
these Claims 26 and 27 in a manner .consistent with that of 
Claim 1. 

Based on the above comments and amendments to the claims, 
Applicants have overcome all basis for the Examiners 35 U.S.C, 
112, second paragraph rejections, and request the Examiner 
withdraw such rejection. 

Next, the Examiner rejected Claim 27 under. 35 U.S.C. 101, 
stating that the claim was directed to non- statutory subject 
matter. The Examiner goes on to state that Claim 27 recites a 
computer program, which Applicants agree with, and that this 
is a bare set of instructions which fails to recite subject 
matter that falls within any statutory category, which Appli- 
cants disagree with. The Examiner gives no rule or statutory 
basis in stating that a computer program or bare set of 
instructions is non- statutory . Applicants traverse this 
rejection with specific statutory language and judicial 
holdings contrary to the Examiner's characterization and 
rejection of Applicants' claimed invention. 

Claim 27 claims a computer program haying 'means for 
presenting items, for selection by a user of a data processing 
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system', and comprising 'means for representing' and 'means 
for dynamically associating' . Means-for elements are specifi- 
cally allowable types of claims, per 35 U.S.C. 112, sixth 
paragraph, without the recital of structure, material, or acts 
and such claim shall be construed to cover the corresponding 
structure, material, or acts in support thereof. 
Therefore, as Applicants' claims cover corresponding struc- 
ture, material or acts, it is erroneous for the Examiner to 
state that these claims constitute non- statutory subject 
matter as being a mere idea or abstract intellectual con- 
cept(see Paper # 4, paragraph 7). As the basis for the 
Examiners rejection is contrary to the statutory language of 
35 U.S.C. 112, this Claim 27 has been erroneously rejected by 
the Examiner. 

Further, the CCPA has held that computer processes are 
statutory unless they fall within a judicially determined 
exception, In re Pardo , 684 F.2d at 916, 214 USPQ at 677 (CCPA 
1982). As was succinctly stated in In re Gelnovatch , 595 F.2d 
32, 201 USPQ 136 (CCPA 1979), "confusion may be avoided if it 
is realized that what is at issue is not the 'program', i.e. 
the software, but the process steps which the software directs 
the computer to perform". The Examiner has failed to show any 
judicially determined exception to computer programs, and has 
wrongfully rejected this claim in. a manner contrary to judi- 
cial holdings. 

The Examiner next rejected Claims 1-27 under 35 U.S.C. 
103 as being unpatentable over Beck et al . The Examiner 
states that Beck teaches "means for representing a plurality 
of ... objects", "means for dynamically associating different 
ones", and "plurality of logical frame presentations based 
upon the data within each of said different ones" at Fig. 5, 
items 27, 40, 41, and 53. Examiner then states that although 
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Beck doesn't explicitly teach "interface objects", that it 
would be obvious because the graphical representations of 
objects taught by Beck could be construed as interface ob- 
jects. Applicants show that Claim 1 would not be obvious in 
view of Beck as follows. 

Amended Claim 1 has the limitation of 'means for dynami- 
cally associating different ones of said interface objects 
with a plurality of logical frame presentations based upon 
data within . . . said interface objects' . Examiner has stated 
that the graphical representations 40 and 41 of Beck Figure 5 
are graphical representations of objects (Paper # 4, paragraph 
10, top. of page 8). Indeed, the Beck graphical representa- 
tions are mere passive representations, and have no means for 
'dynamically associating' as claimed by Applicants. As 
further illustrated and discussed in Beck, Col. 10, lines 
22-25 and 45-50, a user issues commands to a debugger, which 
updates these graphical representations (see also Beck Col 4, 
lines 26-30) . No dynamic association between interface 
objects and logical frame presentations based upon data within 
the interface object is taught or suggested by Beck. Thus, 
Claim 1 was improperly rejected. 

The Examiner rejected Claim 2 in stating that Beck 
teaches the feature of an interface object representing at 
least one attribute of a system resource ,. and cites Beck Col. 
1, lines 62-65 and Col. 3, lines 54-55. Unfortunately, Beck 
states that 'each component of the system can be modeled with 
an object' (Col. 1, lines 62-65), and that these objects have 
code to perform operations (Col. 3, lines 54-55). The Examin- 
er has failed to show where Beck discusses or teaches repre- 
senting attributes of system resources as claimed by Appli- 
cants. Beck's objects merely represent the resources them- 
selves, and not particular attributes of system resources. 

AT9-89-039 8 



PATENT 
07/352,530 



Applicants have added an additional level of detail to the 
resources, which allows for the dynamic associations. As is 
discussed by Beck at Col. 1, lines 62-65, the objects model 
system components such that the components can be simulated by 
the methods corresponding to the objects. No discussion or 
means are provided for particular attributes of a resource. 
Therefore, the limitations of Claim 2 are not taught or 
suggested by Beck. Further, as Claim 2 has all the limita- 
tions of Claim 1, and Claim 1 has been shown to be patentable 
in view of Beck, Claim 2 is similarly patentable. 

Next, the Examiner rejected Claim 3 in stating that Beck 
teaches the claimed feature of representation of hierarchical 
relationships. Again, Applicants claim representing hierar- 
chical relationships 'based upon data within each of said . . . 
interface objects'. Beck's hierarchical representation of 
Figure 6 cannot be construed to be based upon data within 
interface objects, as it has been shown and stated by the 
Examiner that Beck's interface objects are mere graphical 
representations (Beck Col. 4, lines 26-30, and Examiner Paper 
# 4, paragraph 10). These are the output of Beck's debugger, 
whereas Applicant's interface objects define the workings of 
the interface and control software (i.e. they are the 'inputs' 
to the system, and not outputs as are Beck's graphical repre- 
sentations), as discussed in Applicants' specification, page 
7, lines 27-31. Additionally, Claim 3 depends upon and thus 
has all the limitations of Claim 1, which has been shown to be 
patentable. Therefore, Claim 3 has been erroneously rejected 
as is patentable in view of Beck. 

The Examiner rejected Claim 4, in stating that Beck 
teaches the limitation of requiring a dynamic association 
according to hierarchical relationships. Applicants have 
amended Claim 4 to depend upon Claim 3, and Claim 3 was shown 
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above to be patentable. Therefore, for the same reasons, 
Claim 4 is patentable in view of Beck, as Beck has no way of 
representing dynamic association within interface objects. 

Next, the Examiner rejected Claim 5 in stating that Beck 
teaches the feature- of 'means for managing of a screen presen- 
tation' at Beck, Col. 8, lines 10-13. Applicants have studied 
this passage in Beck, and nowhere is discussed the claimed 
limitation 'means for managing of a screen presentation' . The 
passage discusses how a program simultaneously performs 
multiple processes as monitoring a keyboard, mouse, managing a 
clock, running multiple programs, etc. There is no discussion 
on outputting data to a screen, much less how such method is 
performed. Claim 5 also has the limitation of managing screen 
presentation and a user interaction based upon data within ... 
interface objects. Beck's graphical representations are mere 
passive, output elements (Beck, Col. 4, lines 26-30). There- 
fore, Claim 5 would not have been obvious in view of Beck, as 
there is no teaching or suggestion to modify the reference to 
achieve Applicants' claimed invention. 

Claim 6 was rejected by the Examiner as being obvious in 
view of Beck, the Examiner stating that Beck teaches the 
feature of utilizing a current value of a system resource 
attribute at Beck, Col. 2, lines 6-9. Applicants do not see 
how Beck's teachings of 'an object may also provide informa- 
tion to the user through its image on the screen by means of 
data displays or graphical changes to its image' in any way 
teach or suggest Applicants' claimed limitation of 'means for 
utilizing a current value' of a system resource attribute for 
presentation to a user. As previously discussed, Beck's 
objects represent system resources, and do not represent 
underlying attributes of the resource. Thus, Beck could not 
be utilizing a current value of an attribute. Beck merely 
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changes the image being displayed to provide information to a 
user. There is no teaching or suggestion that Beck's graphi- 
cal representations have attributes associated therewith. 
Additionally, Claim 6 has all the limitations of Claim .2, 
which has been shown to be patentable. As such, Claim 6 is 
also patentable in view of Beck, and has been improperly 
rejected. 

The Examiner rejected Claim 7 per the teachings of Beck 
Col. 14, line 63 to Col. 15, line 26. This passage discusses 
objects having instance methods, i.e. multiple invocations of 
an objects' methods are possible. This is not in any way 
germane to what Applicants are claiming, which is 'instance... 
of ... said system resources'. Methods contained within 
objects are not the equivalent of system resources, and so 
method instances are not equivalent to system resource in- 
stances. The distinction is that instances of system re- 
sources are represented by objects (See Specification, page 7, 
lines 1-2), whereas Beck's has instances of the methods 
contained within an, object. For example, a printer might be a 
particular instance of a system resource represented by an 
object, as claimed by Applicants. Beck's method instances 
would be a particular copy of an object's internal mechanism. 
As the instances are distinct and not related, Beck does not 
teach or suggest the limitations of Applicants Claim 7. Thus, 
Claim 7 is patentable in view of Beck. Claim 7 further 
contains all the limitations of Claim 2, which has been 
earlier shown to be patentable, as thus Claim 7 is likewise 
patentable. 

The Examiner rejected Claim 8 as being obvious in view of 
Beck. The analysis for Claim 8 similarly follows from that of 
Claim 7 above, as Claim 8 is dependent upon Claim 7. Thus, 
Claim 8 is patentable in view of Beck. 
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The Examiner rejected Claim 9 in view of Beck teachings 
at col. 14, line 63 to col. 15, line 26. Applicants claim 
'means for utilizing a current value of ... attribute of ... 
system resource for a validation of a user response'. Beck 
does not teach system resources having attributes, or current 
values of attributes being used for validation of user re- 
sponses. Therefore, the limitations claimed by Applicants are 
patentable in view of Beck. Further, Claim 9 includes all the 
limitations of Claim 2, which has been shown to be patentable. 
Therefore, Claim 9 was improperly rejected, and should.be 
allowed. 

The Examiner rejected Claim 10 as being obvious in view 
of Beck, particularly the teachings at Col. 8, lines 1-5. 
This passage of Beck instructs how the Beck debugger is 
invoked by an operator, i.e. how the operator types in a 
command to begin operation of the debugger. This is not what 
is being claimed by Applicants. Applicants are claiming a way 
of constructing a command based upon an input value and an 
option contained within an interface object. When the Beck 
command is input, there are no graphical representations on 
the screen, as the program has yet to be invoked. Further, 
the graphical representations of Beck have no options con- 
tained therein, whereas Applicants are claiming options 
contained within an interface object. Thus, the command line 
invocation of Beck in no way teaches or suggests the limita- 
tions being claimed by Applicants, and Claim 10 is allowable 
in view of Beck. 

The Examiner rejected Claim 11 by stating that Beck 
teaches means for executing command. Applicants maintain that 
Claim 11 is allowable in view of Beck for the reasons stated 
above in regards to Claim 10. 
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Next, the Examiner rejected Claim 12 in stating that Beck 
teaches means for logging command for later execution at Col. 
8, lines 34-37. As Claim 12 depends upon Claim 11, Applicants 
maintain that Claim 12 is likewise allowable for the reasons 
given above for Claims 10 and 11. Further, Applicants main- 
tain that Beck does not teach logging commands for later 
execution. Rather, as is clearly stated at Beck, Col 8, lines 
34-37, a stack is displayed, which contains a list messages 
which have been sent, but for which the target method associ- 
ated with the message has not yet fully executed. In other 
words, a list of messages in progress is displayed. This is 
not what is being claimed by Applicants, who are claiming 
'logging said command for later execution'. This logging is a 
deferral method, not a status indicating method of Beck. 
Thus, Claim 12 has been improperly rejected and is allowable 
in view of Beck. 

The Examiner rejected Claim 13 as being obvious in view 
of the Beck teachings at Fig. 6, item 60.. Applicants traverse 
this rejection for the reasons given in regards to Claim 1, 
upon which this claim is dependant upon. 

The Examiner rejected Claim 14 as being obvious in view 
of the Beck teachings at Fig. 6, item 27. Applicants traverse 
this rejection for the reasons given in regards to Claim 1, 
upon which this claim is. dependant upon. 

The Examiner rejected Claims 15 and 16 as being obvious 
in view of the Beck teachings at Figs. 3-12. Applicants 
traverse this rejection for the reasons given in regards to 
Claim 1, upon which these claims ultimately depend upon. 

Claim 17 was rejected by the Examiner using the teachings 
of Beck, Figs. 3-12. Applicants claim 'means for accessing a 
screen presentation from a plurality of objects'. The graphi- 
cal representations^ of , Beck are mere output representations, 
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and in no way provide any sort of operator or user ability to 
access a screen presentation, as is being claimed. Applicants 
objects are active devices which provide this access capabili- 
ty, whereas Beck's graphical representations are passive and 
offer no functionality. Therefore, Claim 17 was improperly 
rejected, and should be allowed. 

Claim 18 was rejected by the Examiner in view of Beck, 
and in particular Col. 4, lines 42-43. This passage discusses 
displaying indicators when an object either receives a message 
or begins invocation of an object's method. This has nothing 
to do with what is being claimed by Applicants in Claim 18. 
Specifically, the elements of 'altering an object database 
from within the interface during a session of execution' is 
nowhere taught or suggested by Beck. This is a unique capa- 
bility of Applicants' claimed invention, where the underlying 
database can be modified in real time, without the need for 
system regeneration( see Specification, page 8, line 21 to page 
9, line 6). Thus, Claim 18 was improperly rejected as there 
is no teaching or suggestion within Beck of this unique 
claimed feature. Further, Claim 18 depends upon Claim 1, 
which has been shown to be allowable in view of Beck, and is 
likewise allowable. 

Claim 19 was rejected by the Examiner, where it was 
stated that Beck Col. 4, lines 39-40 taught altering object 
database by creating a new object. This is not what Beck 
teaches at Col. 4, lines 39-40. Rather, this passage discuss- 
es updating a visual display, and not an object database. 
There is no connection between status information being 
displayed, and the ability to alter an underlying object 
database. Further, Claim 19 depends upon Claim 1, which has 
been shown to be allowable in view of Beck. Therefore, Claim 
19 was improperly - rejected and should be allowed. 
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Next, the Examiner rejected Claim 20, in stating that 
Beck teaches the feature of entering hierarchy of objects, and 
specifically points to Beck, Col. 11, lines 8-12 and Col. 5, 
Table 1. The Examiner has misunderstood the teachings of 
Beck. The table of Col. 5 is a case in point. This illus- 
trates the Beck teaching of a fixed hierarchy of classes 
relating to an object. It is fixed, relates to classes and 
not objects, and' in no way teaches or suggests 'means for 
directly entering hierarchy of objects', as is claimed by 
Applicants. The discussion at Col. 11, lines 8-12 merely 
discusses the differences between using a step command vs. a 
send command. There is no discussion, teaching, or suggestion 
of directly entering a hierarchical relationship of interface 
objects. Further, Claim 20 ultimately depends upon Claims 3 
and 1, both of which have been shown to be allowable. Claim 
20 is likewise allowable on this ground, as it contains all 
the limitations of Claims 3 and 1. Therefore, Claim 20 was 
improperly rejected by the Examiner in view of Beck, and 
should be allowed. 

Claim 21 was rejected by the Examiner as being obvious in 
view of Beck, and specifically at Col. 10, lines 1-6 of Beck. • 
The Examiner states that Beck teaches means for displaying 
presentations by a plurality of graphical libraries. Appli- 
cants have analyzed the teachings pointed out by the Examiner 
in the Beck reference, and fail to see any teaching or sugges- 
tion for 'displaying said logical frame presentations by a 
plurality of . graphical libraries', as is claimed by Appli- 
cants. This support for plural graphical libraries is another 
key feature of Applicants claimed invention, and allows for 
future applications to use graphical libraries which are 
supplied by' the application, and bypass any existing graphical 
libraries predefined by the system. This additional degree of 
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flexibility in the underlying system design is in no way 
taught or suggested by Beck. There is no teaching of a 
graphical library, nor is there a teaching a supporting a 
plurality of graphical libraries. Further, Claim 21 is 
dependent upon Claim 1, which has been shown to be allowable 
in view of Beck. Claim 21 is allowable for this reason as 
well, as all the limitations of Claim 1 exist in Claim 21. 
Thus, this Claim 21 was improperly rejected by the Examiner, 
as is allowable in view of Beck. 

Claims 22 and 23 were rejected by the Examiner as being 
obvious in view of Beck, in which Examiner states that the 
means for presenting items in at least one of a plurality of 
ways dependent upon a graphical and linguistic context is 
taught at Fig. 6, item 22 of Beck. Applicants wish to point 
out that what is being claimed is 'means, within said inter- 
face objects, for representing'. Beck's graphical representa- 
tions have no means to do anything. They are mere output 
representations, and contained no information within them- 
selves, for representing items in a logical frame in a plural- 
ity of ways depending upon a graphical or linguistic context, 
as is claimed by Applicants. Claim 22 and 23 are also depen- 
dent upon Claim 1, which has been shown to be allowable in 
view of Beck. For the above listed reasons, Claims 22 and 23 
have been improperly rejected and should be allowed. 

Moving to Claim 24, the Examiner rejected this Claim and 
states that Beck teaches means for accessing a screen library 
having means for indicating items outside a visual screen 
presentation at Beck Fig. 6, item 60, and Col. 12, lines 
55-59. Beck does not teach the element of accessing a screen 
library, but rather shows accessing a menu selection box. 
Applicants claim the element of 'means for accessing a screen 
library', and this screen library has 'means for indicating' 
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items. Although the second element is arguably shown by Beck, 
the first item is not. Applicants screen library both filters 
data being sent to the screen and accepts user input (see 
Specification page 27, lines 6-15). This is distinct from a 
box being displayed on a display for indicating items, as is 
taught by Beck. Thus, all the claimed limitations are not 
taught or suggested by Beck. Further, Claim 24 is dependent 
upon Claim 1, which has been shown to be allowable in view of 
Beck. Therefore, all claimed limitations of Claim 24 would be 
allowable in view of Beck, and this claim was improperly 
rejected . 

Claim 25 was rejected by the Examiner, in stating that 
means for providing a presentation dependent upon an access 
control policy is taught by Beck at Fig. 1, item 18 and Col. 
3, lines 65-68. Figure 1 of Beck shows a selection of com- 
mands available to a user. No access control policy is taught 
or suggested. Applicants access control policy is described 
at Specification, page 46, line 19 through page 47, line 7, 
and provides a level of security not provided for by the Beck 
teachings. Beck merely displays a list of commands for a user 
to invoke, and has no means for providing any access control 
policies on commands available for selection. The discussion 
at Beck Col. 3, lines 65-68 merely discusses sending messages 
to initiate a program. Again, no type of access control 
policy is described or suggested. The Examiner is improperly 
reading a function into Beck, which does not exist, in reject- 
ing this claim. Further, this claim includes all the limita- 
tions of Claim 1, which has been shown to be allowable in view 
of Beck. Therefore, this Claim 25 was improperly rejected and 
should be allowed. 

Claims 26 and 27 were rejected by the Examiner for 
reasons substantially the same as Claim 1, and Applicants rely 
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on the arguments made with respect to Claim 1 to traverse this 
rejection. 

In closing, it should be emphasized that the Beck graphi- 
cal representations are mere passive output indicators and 
have no bearing or relationship to the interface objects being 
claimed by Applicants. These interface objects have informa- 
tion contained within the objects themselves, and this infor- 
mation and objects are used to drive (i.e. is an active input 
to) a target system resource. As the functions have no 
bearing or relationship to one another, it would further not 
be obvious to modify the teachings of Beck to achieve Appli- 
cants' claimed invention. 

Applicants request the Examiner to withdraw the rejection 
of these Claims 1-27, as all basis for rejection have been 
overcome, and, pass these claims to issue. 
Respectfully Submitted, 
R. A. Fabbio et al 




Wayne P. Bailey 
Attorney for Applicants 
Registration No.. 34,289 
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